Missing In-link Indicators in Target Module

llandale - Mon Aug 03 15:10:12 EDT 2009
If T doesn't show the in-link then of course you cannot get to the link's properties.

v7.1 had a problem of disappearing ..err.. invisible in-links which came up from time to time for unknown reasons. Although the symptom was seen in the Target module T, the solution was to go to the source module S and run a DXL that looped through all the objects and their links, open up the target module T, and get a handle on the target Object oT. Don't know why but that fixed it. Sounds like the same thing you are doing, access the Link's properties from S.

• louie

llandale - Mon Aug 03 16:47:37 EDT 2009
I see that I opened all the source modules Edit, looped through all the objects and their outlinks, got the module at the other end of the link and opened it Edit as well, and accessed the object at the other end of the link. Even though there were no actual changes, all the modules in question (all the sources and all the targets) were forced 'saved', before closing. Yuuuuuck.

Attached is the script ReDisplayLinks.dxl. It uses functions from my library (they start with 'f': fStatusAdd) but you won't have any trouble figuring them out and dealing with them; for exampe changing 'fOpenModule' to 'edit', removing the 'status' stuff, and replacing the ErrLog with a buffer. Gads, hard to believe I wrote such a sloppy script (2004).

You probably want to run that from all of your Projects. I see that it leaves all the modules open exclusive in the background (Gads, what was I thinking). For large Projects that will cause memory overload, program thrashing, and exponentially longer execution (many hours). I'd be tempted in the Project loop to count the Folders, and SaveAll() and CloseAll() perhaps every 5th folder. Or maybe after each module count the number of open modules, and if its more than perhaps 30 then Save and Close them all.

• Louie

SystemAdmin - Tue Aug 04 06:59:30 EDT 2009
Hi Louie,

Thanks for your help and the script - just have to wait for the problem to reoccur

Cheers, Paul

llandale - Mon Aug 03 16:47:37 EDT 2009
I see that I opened all the source modules Edit, looped through all the objects and their outlinks, got the module at the other end of the link and opened it Edit as well, and accessed the object at the other end of the link. Even though there were no actual changes, all the modules in question (all the sources and all the targets) were forced 'saved', before closing. Yuuuuuck.

Attached is the script ReDisplayLinks.dxl. It uses functions from my library (they start with 'f': fStatusAdd) but you won't have any trouble figuring them out and dealing with them; for exampe changing 'fOpenModule' to 'edit', removing the 'status' stuff, and replacing the ErrLog with a buffer. Gads, hard to believe I wrote such a sloppy script (2004).

You probably want to run that from all of your Projects. I see that it leaves all the modules open exclusive in the background (Gads, what was I thinking). For large Projects that will cause memory overload, program thrashing, and exponentially longer execution (many hours). I'd be tempted in the Project loop to count the Folders, and SaveAll() and CloseAll() perhaps every 5th folder. Or maybe after each module count the number of open modules, and if its more than perhaps 30 then Save and Close them all.

• Louie

SystemAdmin - Wed Feb 10 11:57:56 EST 2010
Hi I have a similar issue, but the ghost link is on the target. The link was removed directly from on the link Module, so in the Target "T" you still see the inlink from the source "S" that currently isn’t linked any more to the target.

By opening the source module, open the destination module and select an object on the target "T' the ghost link disappears, even by opening the properties of the object that still contains the reference and check the links the ghost from the source is not displayed. But by closing the source Module the ghost link reappears on the target "T". Any idea how to eliminate the ghost link on the target "T"?

Regards

Todd_Griffin - Wed Feb 10 13:09:58 EST 2010
Had a similar problem with DOORS 8.3. IBM provided a link repair tool (attached) that work for me. IBM states this utility repairs links in a module with one or both of the following scenarios:

Scenario 1 - An incoming link indicator with no matching outgoing link indicator at the source of the link.
Scenario 2 - An outgoing link indicator with no matching incoming link indicator at the target of the link.

If the link repair utility discovers scenario 1, the link should have been deleted,so the utility removes the incoming link indicator reference from the target object of the link. If the link repair utility discovers scenario 2, the link should have been created so an incoming link indicator reference is created at the target object of the link. The utility will resolve the above scenarios for every object in a module and a log file is created, detailing what the utility has discovered.

Running the utility:

To run this utility, log into the DOORS database as the Administrator user, or as a Database Manager user with full access to all modules in the database. Note: No other users should be in the DOORS database.

IBM provided the following to run the utility:
1. Open the module that contains links that fall into one of the above scenarios, in exclusive edit mode
2. Open the DXL Interaction dialog (Tools->Edit DXL)
3. Click the 'Load' button and locate the file 'inlinks.dxl'.
4. Click the 'Run' button

When the utility is run, the user is presented with a dialog box with a 'Start' button and a path for the log file. The default filename and path for the log file is 'C:\temp\inlink_log.txt', but this can be altered when running the utility. If the default path is not changed, the utility will overwrite the file each time the utility is run.

When the 'Start' button is selected, the user is presented with a progress bar that indicates the current object being processed.
Hope this helps.